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In this sense, the approval steps serve as gates or checkpoints. A developing project 
that fails to satisfy the prescribed criteria will not advance to the next stage of 
development (e.g., it will not advance to the next principal step). If this is the case, 
the project developers have two choices. They may attempt to revise the project by 
5 repeating one or more subtasks in one or more previous principal steps. This is 

indicated by the instruction "revise plan" in FIG. 1 . Alternatively, the developers may 
be forced to abandon the project. This may be appropriate, for example, if it is 
discovered that the project requires resources that cannot be obtained or the project 
has an irreconcilable conflict with another project or other business program. 

10 FIG. 1 indicates that each of the principal steps includes one or more 

substeps. The substeps describe subtasks pertaining to the basic task defined by the 
principal step. The subtasks generally provide a structure and rigor in performing the 
principal tasks. Specific substeps are described below for each principal step. 
However, it should be noted that some IT projects may apply only a subset of the 

1 5 substeps identified below. Other IT projects my add additional substeps to suit 

particular IT applications. Further, in one embodiment, the substeps may be executed 
in any order (e.g., not necessarily in the order described below). 

Having described the process for managing an information technology project 
in general terms, it is now possible to discuss the individual principal steps, substeps, 

20 approval steps, and deliverables in greater detail. 
A. First Principal Step 

The purpose of the first principal step (assess feasibility) is to make an initial 
high-level assessment of whether a particular IT project is worth pursuing. By way of 
overview, this may involve: (1) assessing the benefits that the IT solution may provide 

25 to the organization; (2) determining whether the organization can effectively 
implement the IT solution; and (3) determining whether, once implemented, the 
organization can support the IT solution. The first principal step serves a useful 
function because project management personnel may have numerous demands for 
new or updated IT products, but limited resources. Another purpose of the first 

30 principal step is to ensure that sufficient information has been collected for 
subsequent phases of the project 
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The party responsible for performing the first principal step may comprise an 
appropriate strategy and/or business project leader. A strategy leader typically works 
within an IT group to identify the IT resources necessary to satisfy business 
objectives. A business project leader typically works outside of an IT group to attend 
5 to the needs of the business on a more general level. The first principal step may 
receive inputs (e.g., information and/or other deliverables) from one or more of the 
following individuals or groups: (1) any appropriate personnel from various IT 
technology sectors; (2) any appropriate business personnel; (3) vendors; (4) 
benchmarking entities, etc. Benchmarking entities refer to entities (either inside or 

1 0 outside the organization) that have familiarity with the types of issues presented by 
the current project. These entities thus provide an exemplary baseline against which 
the viability of the current project may be gauged. 

The first principal step may specifically include seven substeps. The first (1) 
substep entails identifying (i.e., collecting) the business requirements associated with 

1 5 the IT solution. This step may involve making a high-level assessment of the 

problems faced by a particular business area within an organization and the resources 
necessary to remedy these problems. 

The second (2) substep involves evaluating technical options. This substep 
may entail defining alternatives to the designated IT solution and examining the 

20 business-related and technical impact of each alternative (e.g., defining what areas of 
the business and technical infrastructure will be affected, and the extent to which they 
will be affected). 

The third (3) substep involves completing a "feasibility form." The feasibility 
form comprises a checksheet which prompts the responsible party to examine and 

25 document various aspects of the project's feasibility. For example, in one exemplary 
case, the feasibility form may prompt the responsible party to: (a) identify how the 
project fits in with other IT projects initiated by the organization; (b) identify how the 
project fits in with the general business plans or initiatives of the organization; (c) 
identify the benefits that the project is projected to provide; (d) identify the level of 

30 service that the IT solution should satisfy based on the expectations and demands of 
the entity receiving the benefits of the solution, e.g., as reflected in high-level 
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"Service Level Agreements" (i.e., SLAs) (e) identify the aspects or elements of the 
project which are regarded as particularly critical to the quality of the IT product (e.g., 
Critical To Quality factors, or CTQs); (f) identify the timeframes for performing the 
tasks of the project; (g) identify major deliverables of the project (e.g., the systems 
5 and/or services generated by the project); (h) identify the scope of the project (e.g., 
identify the metes and bounds of the project's objectives, as well as identify the parts 
and functions of the business that will be affected by the project and the 
considerations raised thereby); (i) identify those individuals (referred to as "business 
champions") who have a strong interest in the success of the project, such as those 

1 0 individuals who typically support the project on a senior leadership level and serve as 
representatives of the project within the organization; (j) identify those individuals 
(referred to as "process owners") who are instrumental in carrying out processes that 
are involved in the project or may be impacted by the project ; (k) review the project 
strategy (e.g., review the strategy to determine what basic architecture and/or 

1 5 processes are envisioned); and (1) identify whether the IT solution has been 

implemented by the organization in the past, and if so, examine the incidents of the 
implementation. 

The fourth (4) substep involves developing a preliminary cost-benefit analysis 
in order to define (by order of magnitude) the costs involved in the project. 
20 The fifth (5) substep involves identifying the major risks posed by the project, 

as well as mitigating factors to these risks. 

The sixth (6) substep involves submitting a request for service (RFS). In one 
exemplary organizational environment, an RFS may comprise a formal request for 
resources required to perform one or more tasks in the project. 
25 Finally, the seventh (7) substep entails determining the schedule, required 

resources, team commitments, and costs involved in performing the second principal 
step, i.e., project initiation. 

The output of the first principal step includes one or more of the following 
deliverables: (1) the feasibility form (defined above); (2) a high level cost-benefit 
30 analysis (e.g., having a specified confidence level, such as 70%); (3) a risk analysis 
form (which itemizes the identified risks of the project); and (4) a cost and schedule 
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